We'll see you next time.
See you next time.
See you next time.
See you next time.
And you would believe me, right?
So, looks like this.
He cries around.
Etiker hears this as well.
So, here's the normal answer.
Here, the etiker appears.
And he answers, I'm this host.
And, well, while that is, he can lie to both parties as well.
So, then it ends up going through his system.
Great.
So, this is a short list of tools.
There are lots of tools to do this stuff.
We did one for Linux and for Windows.
The THC group, another German group, wrote the parasite.
Ittercap is pretty nice because it has a graphical user interface.
So, for all the less educated people here, that's pretty easy.
The classic is Hunt, which is very good, but sometimes strange to handle.
And, yeah, there are scores of others.
Another thing, local redirection.
What do I mean by local redirection?
Most people just overlook this.
By modifying your own system, you can just modify it away.
Okay.
Let's assume the administrator discovers etiker and thinks, okay,
I'm going to fuck this guy.
I'm blocking him here on router one.
Well, okay, end of game.
No, not really.
Etiker could map, let's say, victim's address here, if this guy is forwarding,
to the IP address of router one, just by setting a fixed up entry.
If router one is somehow using MAC addresses for filtering, like, let's say, it's a switching router,
or something, that would pass.
Another way, and that's the recommended way, just modify, yeah, that's the MAC address thing,
just modify your routing table and use router two.
You could even use router two if it had no connection to host B.
Why?
Because router two would know how to send it to router one, and router one would probably accept it.
So, routers.
Okay.
We saw we can do nice things with them, but how do you find them?
There are passive and active ways.
Passive ways basically listen for all the multicast and broadcast stuff, or just discovery protocols, like CDP,
running around the network.
You just map the routers.
But, well, this is not very effective, because most modern routers don't do that.
Routing protocols don't include the actual information in the broadcast packets.
So, what can we do?
We can do active discovery.
We can query routing processes.
We call this AS scanning, because it's autonomous system scanning.
We can send out router solicitations.
I really hate this word.
Which means we just try around and look for a router.
We do OS fingerprinting, or even more interesting, protocol scans.
We just scan the IP protocols, and if it's, let's say, supports IGRP, that's a good hint it might be a router.
Or we just do port scans.
If it is an older model, or just a strange model, and it has, let's say, the RIP port open, well, we find it this way.
This is an example from our ASS, our autonomous system scanner.
The upper four lines, that's passive stuff.
It sees IRDP, broadcasting, router information, and it sees IGRP, two different autonomous systems.
Notice that it includes the iOS version.
Very interesting.
The rest of it is by active scanning, the IGRP in this case, you see how much information you get out there.
It's internal routes or external routes.
You see the net itself, the net mask, the next hop, various information, even what kind of link it was.
And all the information for the routing protocol, like delay, hop count, reliability, and yeah, all that stuff.
So, which jutsu do we have?
As already mentioned, we wrote an autonomous system scanner.
Ethereal is very good in decoding routing protocols.
If you prefer to do your stuff by hand.
Just take this tool.
Nthop can be used to discover central points in the network.
That would be a good hint for a router or a server.
You will find out.
TCP dumps option to show data link addresses is very good.
Because if you see a packet going from A to B on the IP layer, and the destination address on the MAC layer doesn't match to the IP, well, that's the next hop router.
Nmap is pretty good for protocol scan.
We wrote our own tool before we discovered that Nmap supports this.
You basically go down all the IP protocols, and that's a negative scan, so you wait for ICMP protocol unreachable messages.
And if they don't appear, this thing is probably running this protocol.
And if you get a router by DHCP query, well, why not using it?
ICMP router protocol discovery.
Okay, I mixed that up.
IRDP is mostly when you enable this on routers, they broadcast periodic updates.
And just tell everyone, I'm a router.
And I know these interfaces.
And you can talk to me.
IRDP can be requested.
That's this router solicitation stuff.
And he will answer, mostly.
The announcing router, let's say you are the announcing router, is inserted in the host routing table with less priority, means with a higher matrix than the default router.
So make sure the default router is not available.
And the matrix depends on the preference.
Most systems just run with a low preference.
If you use a high preference, you're the first guy.
So how does it look like?
It's pretty straightforward.
You just make sure everyone thinks you are a router.
You send them out.
Make yourself known.
To host A.
And make sure that this guy is temporary not available.
You want to use it later.
Because how are you going to pass the traffic to this cloud here?
So very interesting is the fact if you have a router that runs dial on demand or something.
It has to raise the line or just negotiate PPP or something.
If this host here is Windows, he would think the router is not available.
And take the next one in his routing table, which is hopefully you.
So again, here are the tools.
I recommend this attack as an additional thing.
Because you don't get the traffic right away.
So if you do any kind of traffic interception or redirection,
you can do this in the background just to make sure.
If something goes wrong with your primary attack,
you still get the traffic.
Hosts, as I said, Windows just really likes it.
And does it all the time.
And he just don't boot up.
On the other hand, Linux does not care at all.
ICMP redirects.
Most know these.
They were introduced to make routing a little bit more effective.
So when host A sends traffic to router 1 here,
and router 1 discovers,
shit, I forward this packet to the same segment,
to another router in the same IP network,
which is called router 2,
this is stupid.
And he actually tells this host A.
So host A happily adjusts his routing table
and uses router 2 for disconnection.
So how do we use that?
That works vice versa.
The packet is sent from host A to host B through router 2.
We see this traffic, and we think,
well, we know a better way.
So we actually tell this host A,
please use me as your next hub.
And it works.
It even works extremely well
across routers.
If you send ICMP redirect message,
let's say, across the internet,
that works as well.
Why?
Because the final router who will deliver this packet
to the attacked host
is actually the one who's probably getting all the traffic.
So the host will believe you.
Okay, one important thing here.
There are a lot of redirect tools out there.
But most systems require the first 64 bits
of the original offending packet to be included.
Why?
It would be cool to know which direction
and which communication caused this problem.
So host reactions.
Windows just loves ICMP redirects.
And it just adds the thing to the host
as a host route to his routing table.
So if you look at your routing table
and you have about 500 host routes
on your routing table,
you should look out for ICMP.
Linux host, it depends.
You can set this here in this proc file system.
But most distributions now accept these things.
And it's a little bit evil
because you don't see them in the routing table.
You really have to go into the proc file system
and find out.
So which tools exist?
Okay.
Yeah, because we're speaking about it,
we coded one.
And there's, from URI, another one,
which is basically the original ICMP redirect tool.
Works pretty good.
So this is how it looks like on a Windows system.
You might not read this,
but you see the pattern.
It's all host routing here.
It's all 255.
Okay, let's go routing.
Let's make it interesting.
IGRP, Interior Gateway Routing Protocol.
A Cisco idea.
It has actually 65,535 possible autonomous systems.
It's just to separate several routing processes
from each other.
It uses no authentication.
Hello.
And various things
and it has data link information
like hop count reliability.
Another word I really like.
And bandwidth is used to calculate the matrix.
Well, hosts can actually listen to IGRP
without saying anything.
That's called a passive interface.
So make sure your protocols scan the hosts.
Maybe they accept your updates.
Spoofed updates,
mostly have a better matrix.
Why?
Because you can choose your link however you want
and you can easily compete with the real world stuff.
But keep in mind that your sender network,
whatever you select as your sender network,
has to be enabled as a possible source for route updates.
So how does it look like?
We could introduce new routes
or modifying existing one.
We have this guy here, host B.
And we have this nice server over here.
And we have the three routers here talking IGRP.
Our ad ticker got a connection to another router
and he's just way off.
Okay, so what does he do?
First, he adds the IP address of the server
to his interface.
As a secondary IP.
And enables IP forwarding.
Guess why?
Because in the next step,
he's telling router 1 using router 3's IP address
that 10.1.3.2 is definitely the best way
to reach the server.
So he just makes himself very interesting for the router.
Now, he tells R2 that R1,
is definitely a better route to reach the server
than the original R3.
So, host B actually ends up
logging into his fake server,
running there, submitting his password
and all the other information you just want to have
or just being curious.
We don't do bad stuff, right?
So, and he gets all the traffic.
Great.
He can even run a fake server on it
that looks like the original one.
Think about web applications.
So, you can get a lot of interesting information there.
If, for some reason,
Attica just wants to prevent the server talking to host B,
he can do another thing.
He can do routing loops.
He just tells R3,
well, the best way to reach your host B
is definitely R1.
And he tells R1 that the best way to host B
is definitely R3.
Then, he sits back and enjoys
the packets using up its TTL.
Okay, this is some very old stuff.
Routing information protocol,
version one.
RIP.
Good.
It's one of the oldest,
but it's still in use
because it's so simple.
It uses broadcast
and just runs on UDP port 520.
It has no autonomous systems and other stuff.
It even uses a fixed network size,
at least in most implementations.
And it really, really is easy to attack.
There's the routing information protocol version two.
. . .
It actually includes next-hop information
and netmask into the routing updates.
Still has no autonomous systems,
but it often uses multicast instead of broadcast.
And there is even a clear text authentication
defined in RFC.
But this is so strange
that most people don't implement it
or don't use it.
Cisco actually supports MD5
for RIP.
What a bright idea.
But since they use a double authentication block,
this is not by RFC,
and if you have anything that is not Cisco,
you definitely don't want to run this.
So what are the attacks?
It's basically the same stuff you can do with RIP
as you can do with ERP.
Watch out for the network boundaries
for the fixed netmask stuff,
because if you send updates,
that don't make sense,
or you just use subnetting or supernetting,
you're going to confuse the network.
And we don't want this.
The multicast stuff, RIPv2,
may be forwarded across segments.
Why I love multicasts is,
for example, if you run a checkpoint on an AIX system,
it will forward multicast
whatever the checkpoint setup says.
So that's why I really like it.
Great.
There is a thing called split horizon
with Poisoned Reverse,
which actually prevents routing loops from happening.
Not really.
You have to have at least one router
that knows that there is a routing loop,
and that is communicating back this to the other routers.
If you have just two routers talking RIP,
you can do routing loops.
So which tools exist?
Rprobe and SRIP from Humbl
are probably the first RIP attack tools I've seen,
which doesn't mean anything.
You can use the Nemesis RIP,
or anything else you can think of
based on the libnet,
because they support RIP.
And you can use ASS to scan this.
Problem at the moment is,
the RIP senders I know do not support
the clear text authentication,
which is defined in a RFC,
so you might see that.
OSPF, Open Shortest Path First.
It's a very interesting routing protocol.
Unfortunately, it's very complex.
Basically, one thing it does
is sending out link state advertisements
through the area.
Area means you can define routing areas in OSPF,
and every router,
every router in the area knows the status
of every routing information you might have.
So these halo packets are used to tell each other,
hey, I'm here, and I speak OSPF,
but they don't include much information.
So, yeah.
There's another thing that makes OSPF
more complicated to attack,
because it's basically,
one of the most secure routing protocols currently in use.
Defined in an RFC are clear text and MD5 authentication.
But one thing to remember is,
if you don't understand OSPF,
the administrator might not as well.
So, there's the hard to understand factor.
Let's say, yeah, most people run OSPF in one area,
because they don't know what OSPF is.
because they don't know what OSPF is.
Because it's simple.
So, you might have luck and just have a flawed design.
So how do we attack this?
There are several possible attack ways.
I choose one that's more interesting,
because it's a combination of layer two and layer three attacks.
We spoke about that the attacker is able to decide forwarding,
and is able to modify the IP traffic.
So,
What are we going to do?
Since forged LSAs are often contested by the router,
they have a mechanism called fightback.
So if you just introduce false information,
the routers will cry around and say,
hey, he's a hacker.
So best thing seems to be
you just intercept the communication
between router one and router two.
When router one sends out a packet OSPF-wise,
you just modify the information
and pass it on to router two,
and he will happily distribute it across the area.
Thank you very much.
BGP4, Border Gateway Protocol.
It's an exterior gateway protocol,
which means it's used in vans.
And it's mentioned only here because it's important.
Can anyone think of why BGP is important?
It runs the internet.
So that makes it interesting.
It relies on TCP for communication between routers.
It has a port, 179.
You probably know how to find this.
And more interesting is
there is IDP,
IBGP,
and EBGP.
It means there is an interior BGP
and an exterior BGP.
Interior BGP actually means
how do the routers in one area
communicate with each other?
Yeah, but to find each other
and to do TCP,
they have to have a route.
Okay.
So mostly they use IGP,
and IGP,
or static routes,
which is, okay,
if you have a BGP4 network
and you use static routes,
you're just interesting administrator.
So the best way is often to attack the IGP.
Yeah, because you can just prevent
the routers from speaking to each other.
You could intercept the TCP communication in any way.
Okay.
Or you can use BGP communities.
That's an interesting feature.
It's not fully researched yet
how to do evil stuff with that,
but it is invented to introduce,
let's say, properties
to routers you don't own.
So let's say
UUNet uses communities.
You can,
can actually tell the router, okay, whatever I tell you, it's just for the internet internal
network or whatever you send me, I don't want to have this and that information.
Another one, bad updates. Well, it's not too hard to send bad updates in BGP, but the internet
service providers, especially the small ones, are very good in sending updates like, dear
internet, I actually know where the TEN network is around the world. The backbone providers
got used to that and filtered them pretty good. It's mostly used for internal BGP networks
because you don't want all the hosts in the internet trying to reach the TEN network over
your system. After so much dry routing, here's a fun thing.
Outstand by router protocol, another Cisco idea. It's used to have a virtual or a standby
IP address and another virtual-like MAC address bound to an active router. You have a bunch
of inactive routers. Is the call for me? No? Okay. You have a bunch of inactive routers
sitting there and waiting that the active router dies.
Okay. The active router is sending out hello packets all the time. And if he stops sending
out hello packets, the other routers are going to fight for the highest priority and to actually
get the active state. Interesting is it's first multicast. I already mentioned I love
multicast. And the authentication is done in clear text. Maximum eight characters. Thank you.
So, it basically looks like this. The blue thing down here is this virtual IP address
or standby IP address. So, everyone is talking over router one. When you tell router one
that R2 is actually a new router, just appeared in the network and has a better priority,
this is not as it is designed, but it works. R2 actually gets the standby IP address.
So, everyone is using R2. What's that for? Well, you could actually tell both of them
that you have the highest priority. Can you wait with a question or is it? So, the question
is if there is a key. No, it just uses clear text authentication, but Cisco already went
the way to say, okay, HSRP is kind of interesting and if you really want to use it, use IPSec.
Okay, tell this to .com. Was this a question? Okay. So, yeah, you're telling both of them
you're the best router to do the job and, yeah, at the end you have about 20 risk processors
just for routing. So, you get a virtual IP address and the traffic. And what's the best
about it? It's 100% transparent to the host. The IP address didn't change. The MAC address
didn't change. Everything is like it is before. Just there is this guy here deciding which
traffic is passing.
Well, so, we had a lot of routing and some fun. After so much routing, let's hop into
tunnels. Generic routing encapsulation, GRE, is basically used to transport protocol
A over protocol B in a backpack. It's not even limited to IP. So, normally you use IPv4
and IPv4 to connect six bone islands. You use IPv6 and IPv4. You can transport IPX over
IPv4 or vice versa, whatever. The best authentication you can get with GRE is a 32-bit tunnel key.
There are sequence numbers to prevent evil people, any evil people here? No, to do anything
with the routing protocol, but you can actually forget it, because it's not defined how they
they work. They're far away from being as good as TCP sequence numbers and they're so
bad implemented that it just works if you don't use them.
Another very important thing is GRE supports source routing. Has anyone idea what you can
do with that? So, once upon a time, this is a very common
situation, at least in Europe. The company has an HQ on the right side with
this cute little server and has several branch offices.
We have one on the left side here. So, they were used to using these lines or
something. And because they just hate central authorities,
they just decided, okay, we go for RFC 1918 IP addresses.
Well, they didn't want to do that. So, they just decided, okay, we go for
RFC 1918 IP addresses. Well, they didn't want to do that.
Most of you know these as private IP addresses. So, then they decided, okay, I'm going to
save money. Because we have the Internet, we can pass
over traffic to Internet. Then someone said, hello, your stuff is not
routable. Okay, the carrier, being a good guy and knows
how to do business, offers a VPN solution. It just says, okay, we build a GRE tunnel
between these two. There's one.
And we just encapsulate all the traffic into the tunnel.
And it's passed from the branch office into the tunnel, gone out in an HQ.
And for security, because we want you to use security, it has to be secure, we just
say everything that's not out of the tunnel is dropped directly here on the interface.
And whatever comes into this router and the destination is the same.
The destination is not a local network. We just put it into the tunnel.
So, that makes it perfectly secure. Our poor guy has its own router, and actually
a routable IP address. Anyone noticing the IP address, no?
Okay. So, he's facing the following situation.
He has a network, a target network, let's say this branch office here, which uses not
routable IP addresses. So, he has a network, a target network, let's
say this branch office here, which uses not
a local network. He has an IP address, and uses a filter here
to prevent traffic from coming in. And on top of this, uses GRE.
So, he's lost, isn't he? Not at all.
He just sets up another system. In this case, a concept we call an ATT&CK
router. Then he decides, okay, this system is
my default gateway and he passes traffic to this attack router notice the
destination of his traffic is actually the host here it's not routable anyway
but he's sending this to the attack router the attack router encapsulates
the packet into GRE and the outer packet is addressed to the branch office router
which is getting the traffic seeing that the source address is the HQ guess why
finds out it's GRE cool decapsulates it puts it back on a routing process finds
out he can reach the host over the internal interface and just pass it to
the host so what does the host do the host actually answers the packet
whatever that was
this is what the host department offers and sends it back to his default
gateway the branch office router who will according to his routing rules
encapsulate it into GRE and send it back to the HQ so the HQ router is used for
internet access as well so he knows a way uplink to his provider so he
figures out well this packet is reachable over the Internet
so I just send it out and see our attacker just gets the answer which
means it looks a little bit strange but you're actually talking to a system with
a private IP address across the internet behind the GRE tunnel behind features
and you have fun so since this is so funny we actually put some more work
into this there is at a moment no support for the source routing which
makes it so interesting um a thing to do probably is you can apply the same
attack to IPX encapsulation x25 and attackers in the banking industry here
you can encapsulate i PV for an IP v4 or even attack
IPV4 for IPV4 IPV4 and IPV5 for IPV4 for IPV5 for IPV4 and even attack IPVV and IPV4 or even attack IPV4 for IPV4 and IPV5 for IPV4.
IPv6, six bone islands.
What about taking over an IPv6 host
before it's even on the internet?
Quick ramp up.
What tools do we have?
It's not that interesting, but for reference,
you can download all this stuff here
and the slides on this URL
or actually look at my shirt.
Summary.
There are a lot of ways to alter...
Sorry.
This one.
You can actually grab me
and I can tell you how to ride that.
Okay.
I'll put it back on later.
Summary.
You saw there are many ways to alter traffic paths.
This was not a complete...
Don't go away.
There's a demonstration going on later.
Okay.
This was by far not complete.
There are a lot of routing protocols,
even undocumented ones.
It has still a lot of hack value,
especially the BGP4 attacks.
Most routing protocols, as we saw,
are very interesting protected.
Means nearly nothing.
And unencrypted tunneling protocols.
Are really a high risk
and really demonstrate the fact
that these so-called private IP addresses
do not protect at all.
So, yeah.
Thank you to these people,
especially to these red people
who are shipping me here.
And a special thank you to you,
not falling asleep,
and listening to me here
and being at DEF CON.
And whoever is interested,
I'm going to show the GRE attack now live.
So, now it's getting tricky.
You did real good.
Give me, give me, give me, give me.
Give me, give me, give me, give me.
So, I know I'm probably over my time.
But this is really a fun part to do.
Unfortunately, my laptop has a blank screen now for me.
Just relax.
Okay, what do we have here?
On the left side, upper left side,
we have a tenant session to Cisco router
who is actually representing this branch office thing
I tried to show you in the presentation.
On the right side, top right side,
we have a TCP dump
looking for ICMP
because we are doing simple pings here.
On the lower left side,
we have this already mentioned
Viper thing,
which is our
study in ATT&CK routing technologies.
Louder!
Louder!
Oh, man.
Okay, and on the right side,
you see the local routing table.
So,
what are we going to do?
I'm trying to write
blind here.
Actually, it doesn't work, right?
Can someone up here tell me
whenever I write shit or not?
Actually, it works pretty slow.
Okay, so we ping this one,
and here,
on the right top side,
we see the Cisco
answers actually with administrative
prohibited packages
saying,
bad guy, bad guy, don't send traffic to me, please.
Okay.
So...
Now we have a new routing table.
The new routing table says,
please use this ATT&CK router,
which is this poor little laptop here,
to do the GRE
encapsulation.
I will show the configuration file later,
but it basically just includes
tunnel source and tunnel destination
for this virtual interface here.
So, now,
we actually do
the same thing.
What do we see?
I know it's very
hard to read in the
crowd here, but
on the right side, you see actually
this interface,
this virtual interface, has
the MAC address
double A's, all double A's,
and you actually see that the echo
request is sent to this
virtual interface and then
passed on.
We don't see the pass on here because
someone thought that it's a good idea.
We show something with sniffing and they gave us
a switch. Thank you.
Okay.
Just to illustrate
that you can do
some more stuff
with that.
I'm trying to
write something here.
Does this make sense?
Does it?
Okay.
So,
we actually don't want it to do NSLookups.
Where's the shit?
So,
on the left side, we see the
tunneling packets, which is just
a verbose output.
On the right side, we see
it's actually scanning
through this virtual IP router
and go figure
we bound this IP address on
a loopback of the Cisco, which is
by now pretty clear.
So, that was it. Thank you.
